High-performance telecommunications devices such as packet routers and switches often employ a modular architecture. FIG. 1 illustrates a high-level block diagram of one such router/switch R1 connected in a packet network environment 100. R1 uses a modular chassis where multiple linecards (LC0 to LCn), two route processing modules RPM0 and RPM1, and a switch fabric SF (normally distributed among multiple switch fabric cards, although one is shown) connect to and communicate through a passive backplane 105. High-speed packet traffic enters and leaves router/switch R1 through external linecard ports that couple the device to other packet network devices in a packet network 110. The packet traffic is processed by ingress sections of the linecards and passed through the switch fabric SF to the egress section of an appropriate line card or cards to forward the traffic on to its destination(s).
The route processing modules RPM0 and RPM1 provide overall control of router/switch R1. When two RPMs are included, one is designated as the master, and the other operates in a slave mode that provides redundancy should the first RPM fail in some manner. The master receives and processes packets that are actually addressed to router/switch R1 as a destination, implements various network/switching/routing protocols, shares routing/configuration data with the line cards, and controls scheduling for the switch fabric SF. A backplane Ethernet BE couples the RPMs to each other and to the line cards to facilitate these functions. Each RPM also contains one or more external ports to allow remote management and configuration of router/switch R1 through a dedicated console or packet network-connected device (not shown).
Each RPM and linecard includes one or more general purpose processors. On an RPM, one such processor is designated as the Control Processor (CP) for the entire router. The same processor, or one or more secondary processors on the RPM, are designated as Route Processors (RPs) for the entire router, and run the aforementioned protocols. On each linecard, at least one linecard processor (LP) is responsible for the configuration and management of the packet processing elements on that line card, and typically receives instruction from both the CP and the RPs.
With such a system, the traditional boot sequence is nontrivial and time-consuming due to the large number of processors (e.g., twenty in some implementations), each operating within a specific partition of the system, and yet all working together to achieve full router functionality. FIG. 2 shows a relative boot timeline 200 for two RPMs RPM0 and RPM1 and two linecards LC0 and LC1. Each RPM has a CP and two Route Processors RP1 and RP2. Each linecard has a linecard processor (LP0 and LP1, respectively, for LC0 and LC1).
When router/switch R1 powers up or resets, all of the FIG. 2 processors reset and reference a local boot image. All processors except the CPs use the local boot image to configure their backplane Ethernet connection, and then sit and send periodic requests over the BE for the location of a system image. The CPs, on the other hand, use the local boot image to configure themselves to access a packed image (PI) from one or more repositories on the RPM (e.g., internal or external removable compact flash) or accessible through the RPM's external port(s) (e.g., a FTP server 120 or TFTP server 130 (FIG. 1) connected to packet network 110). The CP may have multiple possible paths to find the PI, and will try the next path in the sequence if it fails to retrieve the PI from the current path.
The packed image PI contains the system images (SIs) for all of the processors in the router, compressed in a single file. The System Image SI for a particular processor contains all the application code necessary for that processor to perform its normal operational functions. When the CP receives the packet image PI, it checks that the PI is error-free, and then decompresses and unpacks the SIs into a protected segment of its local DRAM system memory that is configured as a RAMdisk. The CP validates that its own unpacked SI is also error-free, and then jumps into execution of its SI.
When the CP begins executing its SI, it configures its backplane Ethernet port and attempts to communicate with the CP on the other RPM card, if the router is so configured. When both CPs reach this point in their execution sequence, they negotiate between themselves to elect a master CP, which is the CP on RPM0 in this example. The CP on RPM1 becomes the slave, and continues to boot the SI is slave mode. The CPs eventually reach a point in their SI boot sequences where they are ready to listen to requests from RPs and LPs. The RPs on each RPM request their system images from their respective CPs. The LPs request their system images from the master CP (on RPM0 in this example). The CPs serves these requests by returning to the requesting LP or RP a RAMdisk pathname to the proper SI. Each processor then requests and receives a copy of its SI from the appropriate CP, with the LPs receiving their images over the backplane Ethernet BE. Finally, the RPs and LPs store their respective SIs in local DRAM system memory and jump into execution of the SIs. Eventually, all SIs on all processors are fully booted, and the system is ready to switch and/or route packet traffic.